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Beschreibung 

Verfahren zum tibermitteln von geschtitzten Inf ormationen an 
mehrere Empf anger 

5 

- - Fachgebiet der Erfindung 

■ Die Erfindung betrif ft ein Verfahren gemafi der unabhangigen 
Ansprtiche 1 und 2 . 

10 

In den vergangenen Jahren ist es immer popularer geworden, 

•tiber die verschiedenen Kommunikationsnetze Dienste in An- 
spruch zu nehmen oder Waren zu erwerben. Ein Hinderungsgrund 
war fur den Benutzer bisher immer, dass auch sensible Daten, 
15 wie Kontoinformationen, tiber das Netz tibertragen werden mtis- 
sen. 

In der Figur la ist ein Kaufvorgang vorgestellt, wie er der- 
zeit beispielsweise im Internet durchgefuhrt wird. Auf der 
einen Seite steht der Kunde (Consumer) , der bei einem Verkau- 
20 fer (Merchant) Waren erwirbt. Die Bezahlung dieser Waren soli 
tiber sein Bankkonto erfolgen. Der Consumer ubermittelt nun 
seine Warenanf orderung an den Verkaufer, hier sind verschie- 
dene Informationen denkbar, wie Zusatzinf ormationen (Userin- 
fo) r eine Angabe tiber die gewtinschten Waren (Goods) , sowie 
Information tiber die gewtinschte Zahlunsweise, beispielsweise 
eine Kreditkartennummer . 

Diese Informationen werden dem Verkaufer ubermittelt, etwa 
tiber eine gesicherte Leitung (SSL, Secure Socket Layer, und 
TLS, Transport Layer Security, eine gesicherte Verbindung) . 
30 Diese Verbindung kann zwar von Fremden nicht abgehort werden, 
jedoch erhalt so auch der Verkaufer Informationen, die nicht 
unbedingt ftir ihn bestimmt oder zum AbschluB des Kaufvertra- 
ges notwendig sind, wie eben die Kreditkartennummer. Der Ver- 
kaufer leitet diese Informationen vollstandig an die Bank 
35 weiter, insbesondere auch die Information tiber die gekauften 
Waren, die nicht fur die Bank bestimmt sind. 
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Gewiinscht ware jedoch ein Verhalten, wie es in der Figur lb 
dargestellt ist, so dass der Verkaufer nur die fur ihn wich- 
tigen Inf ormationen tiber die bestellten Waren erhalt und die 
Bank nur die fur sie wichtigen Inf ormationen Ober das Konto 
5 des Kunden. 

Stand der Technik 

10 Verschiedene Losungen sind bereits bekannt. Ein bekannte's 
Produkt auf dem Gebiet der elektronischen Bezahlverf ahren 
wird von der Firma SET Secure Electronic Transactions Lie. 
angeboten. Eine Beschreibung des bekannten Verfahrens findet 
man in der Spezif ikation der Software, die auf ihrer Webseite 

15 http : //www . setco . org/ extensions . html abgelegt sind. Hier fin- 
det sich eine Datenstruktur, die durch zusatzliche Erweite- 
rungen, sogenannte ""extensions", anwendergerecht erganzt wer- 
den kann. 

20 Auch in dieser Losung von SET wird jedoch keine Moglichkeit 
angegeben, verschiedene inhaltlich zusammengehorende Informa- 
tionen, beispielsweise Kreditkartennummern mehrerer Anbieter 
oder Kontoangaben verschiedener Banken, zusammen in einer Da- 
tenstruktur abzulegen. 

25 

Aufgabe der Erfindung ist es also, ein Verfahren zum Ubermit- 
teln von Inf ormationen anzugeben, welches es den Empfangern 
ermoglicht, die fur sie bestimmten Teile der Inf ormationen zu 
lesen. Aufgabe ist es weiterhin, mehrere inhaltlich zusammen- 
30 gehOrige Daten in einer einzigen Datenstruktur geschutzt zu 
tibermitteln. 

Diese Aufgabe wird gelOst durch ein Verfahren gemaB des Pa- 
tentanspruchs 1 und durch ein Verfahren gemaii des Patentan- 
35 spruchs 2. 

GemaB dem Patentanspruch 1 werden erste Inf ormationen, die 
fur einen ersten Empfanger, im weiteren auch Anbieter ge- 
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nannt, bestimmt sind, zusammen mit zweiten Inf ormationen, 
welche far einen zweiten Anbieter bestimmt sind, in einer ge- 
meinsamen Inf ormationseinheit versendet. Die ersten Informa- 
tionen konnen dabei gemafi den Vorgaben des ersten Anbieters 
verschliisselt sein. Die zweiten Informationen, welche aus 
mehreren Bestandteilen bestehen konnen, werden gemaB den Vor- 
gaben des zweiten Anbieters verschlusselt, beispielsweise mit 
einem offentlichen Schliissel, einems sogenannten ^public 
key'' . Diese ^public key'' Verschltisselungsverf ahren sind be- 
reits in verschiedenen Ausftihrungen und Sicherheitsstuf en be- 
kannt. Durch dieses Vorgehen wird gewahrleistet, dass der 
erste Anbieter bei Erhalt der kompletten Information die fUr 
ihn nicht bestimmten Inf ormationsanteile nicht entschltisseln 
kann. 

Der Empfanger der Nachricht wird im weiteren auch Anbieter 
genannt, da in den beschriebenen Beispielen im wesentlichen 
auf einen Kaufvorgang im Netz eingegangen wird. Hier ist der 
erste Empfanger der Nachricht tiblicherweise ein Verkaufer, 
also ein Anbieter von Waren und Dienstleistungen, der zweite 
Empfanger der Nachricht eine Bank oder Geldinstitut, also ein 
Anbieter von Finanzdienstleistungen. Diese Beschreibungen 
sind jedoch nicht einschrankend gemeint. 

Andere Konstellationen sind vorstellbar, beispielsweise ein 
Anbieter von Inf ormationen, der auf weitere Datenbanken zu- 
greift, ein erster Netzbetreiber, der auf ein Netz in einem 
fremden Land zugreift, ein Automobilhersteller oder Polizei, 
die auf die Datenbank der Kf z-Anmeldestelle zugreifen. 

Patentanspruch 2 gibt eine alternative Losungsmoglichkeit an, 
bei der die Informationen, welche fur den zweiten Anbieter 
gedacht sind, nicht mit den ersten Informationen zusammen in 
das Netz geschickt werden, sondern bei Bedarf von dem Infor- 
mationsempfanger aus einem zentralen Speicherbereich im Netz 
abgeholt. werden konnen. 
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Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den 
Unteranspriichen angegeben. 

Als besonders vorteilhaft hat sich eine Realisierung der er- 
f indungsgemafien Losung gemafl dem bereits bekannten Standard 
5 X.509 erwiesen (Series X: Data Networks and Open Systems Com- 
munication - Directory: Public Key an Attribute that Certifi- 
cate Frame Works, ITU-T Recommendation X.509). Eine Realisie- 
rung mit dem X.509-Standard birgt mehrere Vorteile in sich, 
denn dieses Vorgehen ist bereits standardisiert, und kann un- 
10 abhangig von bereits vorhandenen Implementierungen verwendet 
werden. Eine Definition der Datenstrukturen erfolgt in ASN.l 
Notation, welche ebenfalls seit Langem standardisiert ist und 
implement ierungsunabhangig angewendet wird. 

15 Besonders vorteilhaft erweist sich das erf indungsgemafie Ver- 
fahren bei den bereits angesprochenen Zahlungstransaktionen, 
die notwendig werden, wenn man Daten, Inf ormationen und Waren 
tiber das Internet oder ein sonstiges Kommunikationsnetz be- 
stellt oder bezieht und auch die Bezahlung tiber das Netz ab- 

20 wickeln mochte. 

Im Rahmen der bereits bekannten Transaktionen tiber Netze hat 
es sich bewahrt, einem Vorgang eine sogenannte Transaktions- 
nummer (TAN) zuzuweisen, welche einen Kauf vorgang im Netz 
25 eindeutig beziffern und auch nachtraglich zurtickverf olgen 
lassen. 

Die Realisierung der Information durch Ablage in einer Erwei- 
terung eines Zertifikats gemafi dem Standard X.509 kann in 
30 zwei verschiedenen Variationen erf olgen. 

Man kann dieses Zertifikat als sogenanntes Identity Certifi- 
cate realisieren, dieses ist beschrieben im ITU Standard 
X.509, Section 2. Vorteilhaft ist bei dieser Ausftihrung, dass 
35 das Zertifikat sehr kompakt wird, man hat eine "all in one"- 
Losung. 
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Ein Zertifikat in dieser Form ist allerdings im Nachhinein 
nicht mehr anderbar. Daher gibt es als Alternative die Reali- 
sierung in einem sogennannte "Attribute Certificate". Die Be- 
schreibung hierzu findet sich in der Section 3 des bereits 
genannten Standards, Das hat den Vorteil, dass die einzelnen 
Erweiterungen (Extensions) dieses Zertifikats unabhangig von- 
einander sind, deshalb kann man sie jederzeit andern. Ein 
Zertifikat muss auch nicht wider ruf en werden, man muss nur 
abwarten, bis seine Lebensdauer abgelaufen ist. In diesem 
Fall wird das System allerdings komplexer. Der Benutzer muss 
verschiedene Zertifikate behandeln und der Ausgebende der 
Zertifikate muss mehr Certificate Revocation Lists (CRL) ver- 
walten. 

Wahlt man zur Realisierung die zweite Losung, die Attribute 
Certificate Extension, so hat man hier noch die Auswahl, ob 
dieses Zertifikat genau einmal verwendet werden kann, eine 
sogenannte *One Time Use" oder als sogenannte ""Long Life Use" 
einen bestimmten Zeitraum vorgibt, in dem das Zertifikat gul- 
tig ist. 

Zur Ablage des Zertifikats und dazugehorige privaten Schliis- 
sel ist ein geeignetes Speichermedium denkbar, auch wenn das 
Zertifikat zentral im Netz abgelegt wird. Der Eigentiimer des 
Zertifikats kann dieses auch auf eine Smart Card oder einen 
Smart Dongle, auf einem kontaktlos abzulesendem Speichermedi- 
um oder ahnlichem speichern. Hierbei ist es besonders vor- 
teilhaft, wenn das abgelegte Zertifikat zusatzlich durch ein 
Passwort, eine PIN usw. vor unberechtigtem Zugriff geschutzt 
wird. 

Das beschriebene Verfahren kann selbstverstandlich fur alle 
Nutzerinformationen verwendet werden, neben der Kreditkarten- 
nummer, wie Adresse, Blutgruppe, Versicherungsnummern etc.. 

Das vorgeschlagene Vorgehen hat gegentiber dem bereits bekann- 
ten Verfahren verschiedene Vorteile. 
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Eine Verschltisselung und Signierung der Informationen mit be- 
reits bekannten Verfahren ist jederzeit moglich. Dadurch wird 
der Schutz vor unberechtigtem Zugriff (die Privacy) der In- 
formationen gesichert. 
5 Der Diebstahl von Kreditkartennummern, wie es bisher bei- 
spielsweise durch Abhoren der Kauf transaktion geschah, wird 
weiter erschwert. Durch eine zusatzliche Sperre des Zugriff s 
auf gespeicherte Informationen auf dem Speichermedium durch 
Einfuhrung einer PIN wird der Schutz weiter erhoht. 

10 

Kurzbeschreibung der Zeichnungen 

Im Folgenden wird die Erfindung anhand von Ausfuhrungsbei- 
15 spielen erlautert. Dabei zeigen 

Figur la eine Obersicht uber die Verbindungen, die derzeit 
bei einem Kaufvorgang aufgebaut werden, wenn der Kaufer die 
Bezahlung tiber einen Zahlungsdienstanbieter im Netz vornimmt, 

20 

Figur lb zeigt denselben Vorgang, wenn das erf indungsgemaJSe 
Verfahren auf den Zahlungsvorgang verwendet wird, 

Figur 2a zeigt die Zertif ikatserweiterungen fur mehrere Kre- 
25 ditkarten oder ahnliche Informationen, 

Figur 2b zeigt die neuen Primaten OID gemafi X.660 

Figur 3a zeigt das beispielhaf te Format fiir eine Kundenanfor- 
30 derung bei einem Kaufvorgang, 

Figur 3b zeigt das Format fttr die Antwort des ersten Anbie- 
ters, 

35 Figur 3c zeigt das Format fur die signierte Erwiderung des 
Kunden, 
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Figur 3d zeigt das Format ftir die Authentisierungsdaten vom 
zweiten Anbieter, ebenfalls signiert, 

Figur 3e zeigt das Format fiir eine zweite Kundenanf orderung, 

5 

- - Figur 3f zeigt das Format fur eine dritte Kundenanf orderung, 

Figur 3g zeigt das Format ftir eine vierte Kundenanf orderung, 

10 Figur 3h zeigt ein weiteres beispielhaf tes Format fur die Au- 
torisierungsdaten vom zweiten Anbieter, ebenfalls signiert, 

Figur 4 zeigt einen Kaufvorgang in vier Schritten, 

15 Figur 5 zeigt einen Kaufvorgang in acht Schritten, 

Figur 6 zeigt einen Kaufvorgang in zehn Schritten, 

Figur 7 zeigt einen Kaufvorgang mit auftretenden Fehlern, 

20 

Figur 8 zeigt die Struktur des SICRYTT Secure Token, 

Figur 9 zeigt die X.509 Zertifikat Extension Struktur. 

Die Figuren la und lb zeigen, wie in der Einleitung bereits 
beschrieben, den beispielhaf ten Ablauf eines Kauf vorganges . 
In den Kasten ttber den Pfeilen dargestellt, sind die jeweili- 
gen Informationen, die zwischen den einzelnen Verf ahrensteil- 
nehmern fliefien. Der Kontakt des Kaufers (Consumer) geschieht 

30 immer iiber den Verkaufer (Merchant) . Eine direkte Kommunika- 
tion des Kaufers zur Bank findet nicht statt. Alle Informati- 
onen fliefien iiber den Verkaufer. Dies hat zur Folge, dass der 
Verkaufer auch Informationen erhalt, die ftir seinen Verkaufs- 
vorgang unerheblich sind. Durch das erf indungsgemafie Verf ah- 

35 ren, wie in Figur lb dargestellt, werden dem Verkaufer zwar 
samtliche Informationen tibersendet, er kann diese jedoch 
nicht uneingeschrankt lesen. Beispielsweise die Kreditkarten- 
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information (Credit Card Info) , wie hier durchgestrichen dar- 
gestellt, ist dem Verkaufer nicht angezeigt. Andere Informa- 
tionen, etwa wir der Kunde ist (User Info) und was dieser 
Kunde bestellen mochte (Goods) sind ihm frei zuganglich. 

5 

Heutige Public Key Zertifikate versuchen, ein Zertifikat 
(Public und Private Key) auf ein vollstandiges Userprofil ab- 
zubilden. Allerdings hat sich die Anzahl der Anwendungen er- 
weitert, so dass mehr als eine Anwendung (in Zusammenhang mit 

10 beispielsweise Webdiensten) benotigt werden. 

Die erfindungsgem&fie Idee verwendet hierfur ein bereits be- 
kanntes X.509 Zertifikat und erweitert dieses durch zusatzli- 
che Informationen. Diese Informationen werden verschliisselt 
und in dieser Form im Zertifikat abgespeichert . Eine Darstel- 

15 lung hierfur findet sich in Figur 2a. 

Der ursprungliche X.509 Standard wurde entworfen, urn einen 
weltweit einheitliche Namen zu entwickeln fur Benutzer in ei- 
nem Netz, ohne doppeltes Vorkommen, in einem sogenannten 
X.500 Directory. Das X.500 Directory ist eine Datenbank, die 

20 fur weltweiten Gebrauch bestimmt ist, wie ein weltweites Te- 
lefonbuch. Das X.509 Zertifikat wird digital signiert und 
durch eine Zertif izierungsautoritat ausgegeben, um die Iden- 
titat des Inhabers und zusatzliche Informationen zu bestati- 
gen. Public key Verfahren sehen vor, um sicher mit anderen 

25 Telnehmer zu kommunizieren, zwei Schliissel zu generieren: ein 
privaten Schliissel (der geheim bleibt) und einen offentlichen 
Schliissel, der an jeden weiter geben werden kann. Das X.509 
Zertifikat verbindet den Offentlichen Schliissel und den Namen 
des Inhabers des privaten Schliissels. 

30 Vorteil des X.509 Standards ist es, dass er fur eine allge- 
meine Verwendung entwickelt wurde. Hier wird das ganz allge- 
meine Problem der Authentisierung in verteilten Systemen ge- 
16s t und sein Losungsentwurf ist implementierungsunabhangig. 

35 In der Version 3 des X.509 Standards, der 1996 verof f entlich 
wurde, wurden sogenannte Extensions eingefiihrt, bei denen je- 
dermann zusatzliche Datenfelder implementieren und diese in 
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seine Datenstruktur einftihren kann. Diese Erweiterungen wer- 
den auch Private, Proprietary, oder Custom Extensions ge- 
nannt. Sie tragen eindeutige Inf ormationen, die fur den Zer- 
tif ikatinhaber oder Zertif ikataussteller wichtig sind. 
5 Bislang bekannte Erweiterungen sind heute sogenannte *Key U- 
- - sage Limits' 7 , die die Verwendung eines Schliissels auf einen 
speziellen Verwendungszweck beschranken, oder * Alternative 
Names", die der Verkntipfung des Offentlichen Schliissels (Pub- 
lic Keys) mit anderen Namen wie: Domain Namen, E-Mailadressen 
10 etc. ermoglicht . Diese Zertif ikaterganzungen konnen auch als 
kritisch markiert werden urn anzuzeigen, dass die Erganzung 
uberpruft werden muss. 

Im beispielhaf ten Fall eines Zahlungsverkehrs teilt der Be- 
15 nutzer mit verschiedenen Teilnehmern verschiedene ^Geheimnis- 
se", also Daten, die nur dem direkten Kommunikationspartner 
bekannt gegeben werden sollen, beispielsweise bei einem Kre- 
ditkartenausgebenden, wie American Express, Visa, Master Card 
etc., eine Kreditkartennummer oder mit einer Bank die Konto- 
20 nummer oder mit einer Versicherungsanstalt die Versicherungs- 
nummer. Weitere personliche Inf ormationen, wie beispielsweise 
die Adresse, sind vorstellbar. 

Nur der Besitzer des Zertifikats kennt alle diese Erweiterun- 

• gen. Jede einzelne Erweiterung wird dann so verschltisselt, 
dass nur die jeweilige Partner mit der richtigen Identitat 
die entsprechenden Daten wieder entschltisseln kann. 

Hierfur kann beispielsweise das bekannte Public Key Krypto- 
graphie-Verf ahren verwendet werden. Zur Verschlusselung wird 

30 dann der jeweilige offentliche Schlussel der Versicherung, 
der Bank oder des Kreditkartenausgebenden verwendet. Dieses 
wird bei der Ausgabe des Zertifikats verwendet. Danach wird 
das Zertifikat in einem Public Directory abgelegt werden, 
weil nur der jeweilige Ausgebende der Information diese mit 

35 seinem privaten Schliissel entschltisseln (verstehen) kann. 
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Die Erweiterungen sind in dem X . 509-Standard in der ASN1 No- 
tation definiert. Die Figur 2a zeigt eine beispielhaf te Aus- 
gestaltung einer moglichen ausgegebenen Zertif ikaterganzung 
fur einen Benutzer. Dieser Benutzer besitzt drei verschiedene 
5 Kreditkarten (Visa, AmeX, Mastercard) , ein Bankkonto (Bankac- 
count) , weiterhin ist seine Adresse kodiert (Address) und ei- 
ne Versicherungsnummer (Social Insurance Number) . 

Die einzelnen Erweiterung werden durch sogenannte * Object I- 
10 dentifier" (OID) identif iziert . Diese ist eindeutig, was be- 
deutet, dass beispielsweise alle Felder, in denen eine Kre- 
ditkartennummer von einem speziellen Kreditkarteninstitut 
(beispielsweise Visa) immer dieselbe Object ID hat. Im ge- 
zeigten Beispiel der Figur 2b ist diese OID, diese sogenannte 
15 Nummer 1.3.6.1.4.15601.1. Die Definition dieser Object Iden- 
tifier OID befindet sich in der ITU-T Recommendation X.660. 
Die OID kann entweder in einer Baumstruktur abgelegt sein, 
das bedeutet, alle Extensions haben denselben Elternknoten. 
Dieser Fall ist in der Figur 2b dargestellt. Es ist aber auch 
20 moglich, dass die Erweiterungen f irmenabhangig sind. Das be- 
deutet, dass die Erweiterungen an verschiedenen Punktes des 
Baumes eingehangt werden. 

Auch in der Figur 9 findet sich eine Reprasentierung des 
25 X.509 Zertifikats in Baumstruktur. Weiterhin ist in der Figur 
9 zu entnehmen, dass diese Erweiterung nicht blofl als eine 
Bezeichnung und einem Wert bestehen kann, sondern durch wei- 
tere Informationen erganzt werden kann. Im beschriebenen Fall 
der Figur 9 existiert ein weiteres Feld (Crit.), was symbo- 
30 -lisch den Wert *true" oder * false" einnehmen kann. Wird der 
Wert auf true (wahr) gesetzt, so bedeutet dies, dass die Er- 
weiterung als kritisch zu interpretieren ist. Eine mogliche 
Reaktion auf diesen Kritischwert kann sein, dass die Anwen- 
dung, die das Zertifikat erhalt und diese Erweiterung nicht 
35 versteht, das Zertifikat als ungUltig zurtickweisen muss. In 
dem Fall, dass das Flag von kritisch auf false gesetzt ist, 
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kann die Anwendung das Zertifikat trotzdem verwenden, auch 
wenn es diese Extension nicht versteht. 

Die Zertifikate konnen auf verschiedene Weise gespeichert 
werden. Standard Verfahren ist, diese zentral im Netz in ei- 
nem Directory abzulegen. 

Vorteilhaf terweise kann der Eigentumer des Zertifikats dieses 
aber auch auf einem geeigneten Speichermedium mit sich tra- 
gen. Eine bekannte Methode zur Speicherung von solchen Infor- 
mationen sind sogenannte * Smart Cards" . Diese Smart Cards 
sind dem Fachmann bereits bekannt. Vorteil bei der Verwendung 
einer Smart Card ist, dass der Zugriff auf den Speicher, in 
dem das Zertifikat (eigentlich der private Schlussel) abgelegt 
ist, zusatzlich durch eine PIN oder entsprechendem Pafiwort 
geschutzt werden kann. Im Falle mehrfacher falscher PIN- 
Eingabe wird dann der Zugang zum Speicher der Karte bio- 
ckiert . 

Andere Speichermedien sind jedoch vorstellbar. 
In der Figur 8 findet sich eine Darstellung der Infineon Sic- 
ript Secure Token Plattform. Diese Plattform bietet zwei Stu- 
fen an Speicher zugang an. Der Userlevel ist mit einer soge- 
nannten *User PIN" geschutzt und der zweite Level mit einer 
weiteren * Administrator PIN" . Diese * Administrator PIN" kann 
verwendet werden, urn nach mehrfachem falschen Eingeben der 
^User PIN" die Karte wieder zu entsperren. 

Das Speichern des Zertifikats auf einer Smart Card hat diese 
. Vorteile: 

Sicherheit: 

30 Das X.509 Zertifikat und der zugehorige private Schlussel 

werden in zwei verschiedenen sogenannten * Elementary Fi- 
les" (EF) abgespeichert, siehe Figur 8. Der schreibende 
Zugriff zu der entsprechenden Datei DF C sp ist mit einem Zu- 
gangscode geschutzt. Das Elementary File EF Key pair ist ge- 

35 nauso geschutzt. Jede Anwendung oder jeder Dienst, der den 

Zugriff zu dem privaten Schlttssel benotigt, muss genau 
diesen Zugangscode vom Benutzer erhalten. Dahingegen kann 
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die Ablage cies EF Ce rtificate immer gelesen werden, ist also 
nicht geschtttzt. Das Zertifikat in das System zu propagie- 
ren bedeutet in diesem Fall also lediglich das Kopieren 
des Zertifikats zu dem System. 

5 

Mobilitat: 

Smart Cards sind tragbare Speichermedien und wegen ihrer 
GroJie kann der Benutzer sie beispielsweise in seiner 
Brieftasche mit sich tragen. Weiterhin kann er sie an sei- 

10 nem PC mit einem entsprechenden Lesergerat verwenden, ge- 

nauso an offentlichen Terminals (beispielsweise in einem 
Internetcafe) . Der Benutzer braucht dabei nicht zu be- 
fiirchten, dass der private Schliissel kopiert wird oder im 
System verbleibt. Auch wenn der Benutzer seine Smart Card 

15 verliert, kann auf diese ohne den Zugangscode (PIN) nicht 

zugegriffen werden. 

Kompaktheit: 

Durch das erf indungsgemafie Abspeichern der verschiedenen 
20 Zahlungsmoglichkeiten (beispielsweise alle Kreditkarten- 

nummern und alle Kontonummern) auf einer Karte, ist diese 
besonders kompakt. Ein derartiges Abspeichern in einer Da- 
tenstruktur ist dem Fachmann bislang nicht bekannt. Wei- 
terhin konnen weitere Inf ormationen (zum Beispiel die Ad- 
25 resse usw.) integriert werden und machen das Userprofil 

damit noch kompakter. 

Im Folgenden wird nun die Durchfiihrung eines Zahlungsvorgangs 
mit dem X.509 Zertifikat beschrieben. In den Figuren 3a bis 

30 3h sind verschiedene Moglichkeiten der einzelnen Nachrichten 
abgebildet, die vom Nutzer, dem Verkaufer oder der Bank im 
Verlauf des Zahlungsvorgangs benutzt werden konnen. 
Die Obermittlung dieser Nachrichten erfolgt beispielsweise 
tlber das Internet, andere Mobilfunk- oder Festnetze sind vor- 

35 stellbar. 
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Voraussetzung des Verfahrens ist, dass bereits durch den Nut- 
zer eine Auswahl des Produkts erfolgt ist, sowie der Preis 
ftir dieses Produkt verhandelt wurde. Die Nachrichteneinheiten 
werden auf Application Level beschrieben, das bedeutet, es 
5 sind keine Bytes trukturen angegeben. Weiterhin sind die Teil- 
- - nehmer des Verfahrens'' online" , also dauerhaft mit dem Netz 
verbunden. 

In einem beispielhaf ten ersten Ablauf sind der Kunde (Consu- 
10' mer) , der Verkaufer (Merchant) und die Bank uber ein Netz, 

beispielsweise das Internet, verbunden. Dies soli aber keine 

•Einschrankung ftir das Verfahren darstellen, andere Verbin- 
dungsmoglichkeiten sind denkbar. Die Schritte 1 bis 10 der 
Figur 6 werden in sequentieller Folge durchlaufen. Dabei wird 
15 angenommen, dass der Austausch des X.509 Zertifikats zwischen 
dem Verkaufer (Merchant) und der Bank bereits geschehen ist. 

■ 1. Der Kunde fordert vom Merchant (Verkaufer) den offentli- 
chen Schlttssel an, sofern er ihn noch nicht hat (Request 
20 Cert. ) . 

2. Der Verkaufer sendete sein Zertifikat (Send. Cert.) an den 
Kunde n . 

3. Der Kunde validiert das Zertifikat. Dabei tiberprUft er 
beispielsweise, ob die Zeitgultigkeit noch nicht abgelau- 
fen ist, und ob das Zertifikat von einer vertrauenswurdi- 
gen Autoritat ausgestellt wurde. Dann sendet der Kunde 
seine Kauf anforderung an den Verkaufer (Purchase Order) . 
Die Kauf anforderung kann das Format haben, wie es in Figur 
3a dargestellt ist. In diesem Fall sind die Angaben der zu 
kaufenden Waren verschlUsselt mit dem offentlichen Schltis- 
sel des Verkaufers (E (Merchant pU biickey/ goods), dagegen ist 
das X.509 Zertifikat nicht verschliisselt . Das Versenden 
des X.509 Zertifikats in dieser Nachricht ist optional. Im 
anderen Fall holt sich der Verkaufer dieses Zertifikat aus 
einem offentlichen Verzeichnis. Das Zertifikat ist nur in 
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dem Teil verschlusselt, der die Kreditkarteninformation, 
wie vorher beschrieben, enthalt. 

4. Der Verkaufer entschliisselt diese Nachricht mit seinem 
5 privaten Schliissel. Er prttft auch hier die Gtiltigkeit des 

Zertifikats auf folgende Bedingungen: 

1st das Zertifikat von einer vertrauenswtirdigen Autori- 
tat ausgestellt, 

1st die Lebensdauer des Zertifikats uberschritten, und 
10 - 1st das Zertifikat nicht in der CRL (Certificate Revo- 

cation List) . 



Erfullt das Zertifikat eines der oben genannten Kriterien 
nicht, so markiert der Verkaufer es als ungtiltig und been- 

15 dete die Sitzung mit dem Kunden. 

Anderenf alls, also wenn das Zertifikat gultig ist, sendet 
der Verkaufer das Zertifikat des Kunden an die Bank oder 
an den Kreditkartenausgeber (Verify Account) , urn die im 
Zertifikat angegebene Kreditkartennummer zu verif izieren. 

20 Diese Kreditkartennummer ist, wie bereits beschrieben, in 

der privaten Erweiterung des X.509 Zertifikats* gespei- 
chert, und dort nur verschlusselt zu entnehmen. 

5. Die Bank uberprtift das vom Kunden empfangene X.509 Zerti- 
25 fikat. Die Uberpriifung beinhaltet: 

Kommt das Zertifikat von einer vertrauenswtirdigen Zertifi- 
kat saut or i tat, 

ist das Zertifikat abgelaufen, 

ist das Zertifikat in der CRL (Certificate Revocation 
30 List) und 

hat das Zertifikat die Erweiterungen, die die Informatio- 
nen tiber Kreditkartennummern oder Kontonummern enthalten. 



Ist das Zertifikat als gultig erkannt, so uberprtift die Bank 
35 nun den in der Erweiterung spezif izierten Account. Ist das 

Konto gesperrt oder iiberzogen, dann sendet die Bank eine ne- 
gative Antwort an den Verkaufer. Es ist vorstellbar, dass ein 
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vordefinierter Set an Antwortcodes zu jedem moglichen Status 
des Kundenkontos definiert wird, um diesen Kundenstatus zu 
propagieren. 

1st jedoch das X.509 Zertifikat auch in diesem zweiten Check 
positiv iiberprtift, das heisst, das Konto existiert und ist 
belastbar, so sendet die Bank einen speziellen Code, auch als 
Transaktionsnummer (TAN) bekannt, an den Verkaufer zuruck 
(Transaction Number) . Diese TAN ist in der Regel eine zufal- 
lige Zahl, die eindeutig diese Transaktion identif izieren 
soil . 

Diese Transaktionsnummer kann auch noch mit zwei Flags be- 
wahrt werden, einen „Angef order t m und einen „Benutzt* Flag. 
Wenn die Transaktionsnummer zu dem Verkaufer gesendet wird, 
dann wird der Zustand auf "Angefordert" gesetzt. So kann die 
Bank Falschungsversuche durch Kopieren dieser Transaktions- 
nummer verhindern. Die Bank verschlusselt die Transaktions- 
nummer mit dem offentlichen Schlussel des Verkaufers und sen- 
det es an den Verkaufer zuruck. 

6. Der Verkaufer evaluiert die Antwort der Bank und ent- 
schliisselt diese mit seinem privaten Schlussel. 
Ist die Antwort negativ, so beendet der Verkaufer die Sit- 
zung mit dem Kunden. 

Im anderen Fall, wenn die Antwort positiv ist, so muss ei- 
ne Transaktionsnummer von der Bank enthalten sein. Der 
Verkaufer formatiert die Antwort auf die Kaufanfrage des 
Kunden, diese Antwort ist beispielhaft in der Figur 3b 
dargestellt. Enthalten ist hier die Kaufsumme (Amount), 
der Name des Kunden (Client Name) , die verschlusselte Kon- 
tonummer, welche aus dem X.509 Zertifikat entnommen wurde 
(Account Encrypted), dann die angeforderten Waren (Goods) 
und die von Bank gelieferte Transaktionsnummer (TN) . Die 
Zeit (Time) entspricht der Zeit am Server des Verkaufers 
und Name (Name) entspricht dem offiziellen Namen des Ver- 
kaufers, so wie es auch in tiblichen Kreditkartentransakti- 
onen verwendet wird. Der Kundenname und das Kundenkonto 
wird vom Zertifikat des Kunden entnommen. Um eine erhohte 
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Privacy zu garantieren, konnen auch die eingeftigten Waren 
verschltisselt sein, hier dargestellt durch eine Hash- 
Funktion. Der komplette Datensatz wird dann mit dem of- 
fentlichen Schltissel des Kunden verschltisselt und zum Kun- 
5 den geschickt (Request Sign Order) . Vorteilhaf terweise 

speichert der Verkaufer diese Anforderung, insbesondere 
die Adresse und die Waren (Goods) , fur einen spateren 
Versendungsprozess . 

Der Kunde empfangt die Nachricht vom Verkaufer und sig- 
niert diese digital (Dig. Signature) . Dieses ist zu erken- 
nen in der Figur 3c. Fur die Signierung verwendet er sei- 
nen privaten Schltissel. Wahlweise kann er mit Hilfe der 
Hash- Funkt ion seine Waren tiberprtif en. 

Die digitale Signatur spielt hierbei eine doppelte Rolle: 
Zum Einen stellt es sicher, dass die Daten wahren der 0- 
bertragung nicht geandert worden sind und zum Anderen sei- 
tens der angeschriebene Kunde dem Kunden entspricht, der 
die ursprtingliche Anforderung gesendet hat. Damit stellt 
es sicher, dass es sich tatsachlich urn den Inhaber des 
X.509 Zertifikates handelt. Der Kunde verschltisselt nun 
die komplette Nachricht mit dem offentlichen Schltissel des 
Verkaufers und sendet es an den Verkaufer zuruck (Sign Or- 
der) . 

Der Verkaufer empfangt die verschltisselte Nachricht und 
entschltisselt sie mit seinem privaten Schltissel. Dann ver- 
schltisselt er sie mit dem offentlichen Schltissel der Bank 
oder des Kreditkarteninstitutes . In diesem Schritt handelt 
der Verkaufer nur in einer Routerfunktion (Verify Sign Or- 
der) . Das Format der Nachricht entspricht demselben wie in 
Schritt 1, siehe Figur 3c. 

Die Bank entschltisselt die vom Verkaufer empfangene Nach- 
richt mit seinem privaten Schltissel. Danach wird die Sig- 
natur der Kundenanfrage verifiziert. Die Transaktionsnum- 
mer, die in der Nachricht vorhanden sein muss, muss auf 
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"Ange f order t" gesetzt sein, wie vorher geschrieben. Ande- 
renfalls ist dies ein Hinweis, dass der Verkaufer versucht 
hat, die Nachricht zu duplizieren. Nach Empfang der Trans- 
aktionsnummer setzt die Bank das zweite Flag ftir die 
Transaktionsnummer in seiner Datenbank auf "Benutzt". 
Die Bank generiert nun einen Autorisierungscode und forma- 
tiert die Daten wie in der Figur 3d angezeigt. Zeit (Time) 
und Bankname entsprechen dem in Schritt 6 beschriebenem. 
Sicherheitshalber kann die Bank nun diese Nachricht digi- 
tal unterschreiben mit ihrem Autorisierungscode. Die kom- 
plette Nachricht wird danach verschliisselt mit Hilfe des 
offentlichen Schliissels des Verkauf.ers und an den Verkau- 
fer gesendet (Auth. Code) . 

10, Sofern der Autorisierungscode der empfangenen Nachricht 
positiv ist, versendet der Verkaufer seine Waren oder 
macht den angeforderten Dienst far den Kaufer verfugbar. 
Weiterhin zieht er den angeforderten Geldbetrag nun vom 
Kreditkarteninstitut oder der Bank ein. Dann informiert 
der Verkaufer den Kunden, dass die Transaktion erfolgreich 
durchgefuhrt wurde (Notification) . Diese Nachricht wird 
wieder mit dem offentlichen Schlussel des Kunden ver- 
schliisselt. 

Der im Vergangenem beschriebene Transaktionsprozess kann aber 
auch in der Anzahl der Schritte reduziert werden (siehe hier- 
ftir die Figur 5) . Voraussetzung ist in diesem Fall, dass zwi- 
schen jeweils zwei Teilnehmern, dem Kunden und dem Verkaufer, 
und dem Verkaufer und der Bank, eine sichere Kommunikation, 
beispielsweise uber SSL etabliert ist. Weiterhin wird ange- 
nommen, dass eine gegenseitige Authentisierung, basierend auf 
den X.509 Zertif ikaten, zwischen den jeweiligen Teilnehmern 
bereits geschehen ist. 

Die Schritte 1 bis 8 werden sequentiell ausgeftihrt. Das For- 
mat der Datenpakete ist dasselbe wie in dem vorangegangenen 
Beispiel der Figur 6 beschrieben. In diesem Fall besteht kei- 
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ne Erfordernis ftlr eine Verschlusselung, da die Verschltisse- 
lung durch die SSL-Verbindung bereits gewahrleistet ist. Des- 
halb spart man in diesem Prozess zwei Schritte ein. Im Prin- 
zip sind die ersten zwei Schritte des Prozesses in Figur 6 
5 eingespart, so dass der Schritt 1 der Figur 5 dem Schritt 3 
der Figur 6 entspricht. Der Schritt 2 der Figur 5 entspricht 
dem Schritt 4 der Figur 6 und so fort. 

Ein Verkauf svorgang mit einem minimalen Nachrichtenaustausch 
10 ist in der Figur 4 dargestellt. In den beiden vorangehenden 

Beispielen wurde der Vorgang in zwei Schritten durchgefuhrt, 

das Bestellen und im zweiten Schritt die Signierung der Be- 

stellung. Figur 4 zeigt nun einen Vorgang, wo beide Schritte 

in einem Schritt zusammengef asst werden. 
15 Weiterhin ist in diesem Vorgehen auch keine Trans aktionsnum- 

mer der Bank erf orderlich. Die Transaktionsnummer wird in 

diesem Fall von dem Kunden selber erzeugt. 

Der Nachrichtenf luss funktioniert im Folgenden: 

20 1. Der Nutzer bereitet eine Anforderung (Sign Purchase Order) 
vor, er generiert sich eine Transaktionsnummer (die in 
diesem Fall eine wirkliche Zuf allsnummer ist TN) , und die 
gegen Kopierattacken verwendet wird. Das Format der Nach- 
richt ist in der Figur 3e abgebildet. Das Feld "Zeit" rep- 

25 rasentiert die Transaktionszeit beim Kunden. Name und Kun- 

dennummer (Account) sind Werte, die aus dem Zertifikat des 
Kunden X.509 entnommen wurden. Die Suitime (Amount) repra- 
sentiert die Hohe der Summe dieser Kauf transaktion. 
Der Verkaufer (Merchant) ist als Name oder auch als ID, 

30 wie Ublicherweise in Kreditkartentransaktionen, verwendet. 

Ein Hashwert ermoglicht es, dem Kunden seine Auflistung 
der georderten Waren gegenuber der Bank zu verschltisseln, 
der Hash-Algorithmus ist dem Fachmann bekannt. 
Weiterhin ist in der Nachricht eine digitale Signatur 

35 (dig.sig.) enthalten, die die vorangegangenen Daten sig- 

niert. Diese Signatur versichert dem Verkaufer und der 
Bank, dass der Kunde die Transaktion selber initiiert hat, 
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und dass er der Besitzer des korrespondierenden privaten 
Schltissels ist und die Transaktionsdaten wahrend der Uber 
tragung nicht geandert worden sind. 

Das Feld "War en 11 (Goods) reprasentiert die vom Kaufer aus 
gewahlten Waren, die gekauft werden sollen oder auch die 
Dienstleistung, dieses Feld muss ftir den Verkaufer lesbar 
sein, urn im Zweifelsfall die Anforderung vervollstandigen 
zu konnen. 

Der Kunde hangt sein X.509 Zertifikat mit dem in den Ex- 
tensions enthaltenen verschlusselten Kreditkartennummern 
an die Nachricht an. Wenn diese Nachricht uber das Inter- 
net verteilt wird, dann sollte der Kunde diese Nachricht 
zusatzlich mit dem offentlichen Schltissel des Verkaufers 
verschltisseln. 

2. Der Verkaufer uberprttft das Zertifikat des Kunden auf fol 
gende Bedingungen: 

Ist das Zertifikat von einer vertrauenswtirdigen Autori 
tat ausgegeben, 

ist die Lebensdauer des Zertifikats abgelaufen, und 
- ist das Zertifikat in der CRL (Certificate Revocation 
List) . 

Wenn die Oberpriifung des Zertifikats eine Fehlermeldung 
produziert, dann markiert der Verkaufer dieses als ungul- 
tig und beendet die Sitzung mit dem Kunden. Der Verkaufer 
hat aufierdem die MQglichkeit, die digitale Signatur zu 
prufen, beispielsweise indem er tiberpruft, ob der Kunde 
den entsprechenden privaten SchlUssel besitzt. Der Verkau- 
fer entnimmt das Feld "Waren" (Goods) aus der enthaltenen 
Nachricht urn sicherzustellen, dass diese Inf ormationen 
nicht an die Bank gelangen, und leitet die restliche Nach- 
richt an die Bank weiter (Verify Sign Order) . 

3. Die Bank tiberpruft das X.509 Zertifikat des Kunden auf 
Grund folgender Punkte: 
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1st das Zertifikat von einer vertrauenswtirdigen Autoritat 
ausgestellt, 

ist das Zertifikat abgelaufen, 
ist das Zertifikat in der CRL enthalten und 
5 - hat das Zertifikat die privaten Erweiterungen, die die 

Kreditkartennummer oder Kontonummer des Kunden enthalten. 

Stellt sich das Zertifikat als gtiltig heraus, so verifi- 
ziert die Bank die digitale Signatur um sicherzustellen, 

10 dass die Transaktion tatsachlich vom Kunden ausgelost wur- 

de. Danach tiberprtift die Bank das Konto des Kunden oder 
das Kreditkartenkonto, welches in dem X.509 Zertifikat 
enthalten war. Ist diese Kontonummer gesperrt oder ist das 
Konto Uberzogen, so sendet die Bank eine negative Antwort 

15 an den Verkaufer. Im anderen Fall, also wenn das Konto 

verfiigbar ist, so sendet die Bank eine Antwort (Auth. Co- 
de) zuruck, wie sie in der Figur 3f dargestellt ist. In 
diesem Fall bezeichnet das Feld "Name" den Namen der Bank 
oder des Kreditkarteninstituts . Die Bank signiert diese 

20 Nachricht danach mit ihrem privaten Schliissel. 

4. Im letzten Schritt macht der Verkaufer nach Erhalt des po- 
sitiven Autorisierungscodes die Waren fur die Kaufer zu- 
ganglich oder auch die angef orderten Dienstleistungen (No- 
25 tification) . Weiterhin zieht er das angeforderte Geld vom 

Kreditkarteninstitut ein. 

Das Protokoll, das- in diesem Abschnitt beschrieben ist, kann 
beispielsweise auch uber http (HyperText Transfer Protocol) 

30 oder https (HyperText Transfer Protocol Secure) ablaufen. Im 
Falle von http sollten die Nachrichten mit dem jeweiligen 6f- 
fentlichen Schliissel des Absenders verschltisselt werden. 
Falls zwischen dem Verkaufer und der Bank ein anderes siche- 
res Netzwerk existiert, beispielweise ein privates Banknetz 

35 oder ein VPN (Virtual Private Network) , so kann auf eine Ver- 
schlusselung verzichtet werden. 
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Die Figuren 3g und 3h stellen weitere Nachrichtenf ormate dar, 
die alternativ zu den bereits beschriebenen, aus den Figuren 
3a bis 3f verwendet werden kSnnen. Die Nachricht aus der Fi- 
gur 3g ist beispielsweise ein anderes Format fur die Nach- 
richt aus der Figur 3c. Die Figur 3h stellt ein Nachrichten- 
format entsprechend der Figur 3d dar. Dies soli deutlich ma- 
chen,. dass die entsprechenden Nachrichtenf ormate nur bei- 
spielhafter Natur sind und selbstverstandlich beispielsweise 
durch erganzende Felder verandert werden konnen. 

Der Prozess, der in Figur 7 dargestellt ist, entspricht im 
Wesentlichen dem Vorgehen der Figur 6 mit der einzigen Aus- 
nahme, dass die negativen Antworten (Return (False)) bei 
fehlgeschlagener uberprtifung von Zertifikaten mit eingefugt 
sind. 

Eine Realisierung der erf indungsgemaflen Idee wurde bereits 
erprobt. Hier wurde das Windows XP als Betriebssystems ver- 
wendet, .NET Studio als Entwicklungsumgebung WES (Web Service 
Enhancements) als ein Extramodul fur die Erzeugung von X.509 
Zertifikaten. CAPICOM-Module ftir die Manipulation der Zerti- 
fikate, zum Beispiel, Signieren, Entschlvisseln, Verschliis- 
seln, Verifizieren usw. Open SSL ftir die Herausgabe der not- 
wendigen Zertif ikatextensions . Als Smart Card die Infineon 
Secrypt Smart Card und zugehorigen Tools ftir die Installation 
der Zertif ikate. 
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Patentansprtiche 

1. Verfahren zur trbermittlung von ersten Informationen (Enc- 
rypted Goods) von einem Nutzer (Consumer) eines Telekoramu- 
nikationsnetzes an einen ersten Anbieter (Merchant) 

und von zweiten Informationen (X.509 Identity Certificate) 
von diesem Nutzer (Consumer) an einen zweiten Anbieter 
(Bank) , 

bei dem die ersten Informationen (Encrypted Goods) gemafi 
Vorgaben des ersten Anbieters (Merchant) verschlusselt 
sein konnen und 

bei dem die zweiten Informationen einen ein- oder mehrtei- 
ligen Bestandteil (Credit Card Info) enthalten, der gemafi 
Vorgaben des zweiten Anbieters (Bank) verschlusselt ist 
und bei dem die Informationen in einer gemeinsamen Infor- 
mationseinheit versendet werden. 

2 . Verfahren zur trbermittlung von ersten Informationen (Enc- 

rypted Goods) von einem Nutzer (Consumer) eines Telekom- 
munikationsnetzes an einen ersten Anbieter (Merchant) 
und von zweiten Informationen (X.509 Attribute Certifica- 
te) von diesem Nutzer (Consumer) an einen zweiten Anbie- 
ter (Bank) , 

bei dem die ersten Informationen gemafi Vorgaben des ersten 
Anbieters (Merchant) verschlusselt sein konnen und 
bei dem die zweiten Informationen einen ein- oder mehrtei- 
ligen Bestandteil (Credit Card Info) enthalten, der gemafi 
Vorgaben des zweiten Anbieters (Bank) verschlusselt ist 
und bei dem die zweiten Informationen von dem ersten oder 
zweiten Anbieter aus einem von dem ersten und zweiten An- 
bieter zugreifbaren Datenspeicher abgelegt sind. 

3. Verfahren nach Patentanspruch 1 oder 2, 

dadurch gekennzeich.net, dass 

zur Ablage der zweiten Informationen eine private Erweite- 
rung eines Zertifikates gemafi dem Standard X.509 verwendet 
wird. 
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4. Verfahren nach einem der vorigen Patentanspriiche, 
dadurch gekennzeichnet , dass 

es fur eine Zahlungstransaktion verwendet wird und die li- 
bertragenen ersten und/oder zweiten Inf ormationen sich auf 
die Zahlungstransaktion beziehen. 

5. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet, dass 

dem Zahlungsvorgang von dem zweiten Anbieter oder von dem 
Nutzer eine eindeutige Transaktionsnummer (TAN) zugewiesen 
wird. 



6. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet, dass 

eine Identity Certificate Extension verwendet wird. 

7. Verfahren nach Patentanspruch 4, 

dadurch gekennzeichnet, dass 

eine Attribute Certificate Extension verwendet wird. 

8. Verfahren nach Patentanspruch 7, 

dadurch gekennzeichnet, dass 

ein Attribute Certificate genau einmal verwendet werden 
kann . 

9. Verfahren nach eineia der vorigen Patentanspriiche, 

dadurch gekennzeichnet, dass 

zur Ablage des Zertifikats ein geeignetes Speichermedium, 
insbesondere eine Smart Card, ein Smart Dongle oder ein 
kontaktlos abzulesendes Speichermedium verwendet wird. 

10. Verfahren nach einem der vorigen Patent ansprttche, 
dadurch gekennzeichnet, dass 

das Zertifikat mit einem Passwort geschutzt auf dem Spei- 
chermedium abgelegt ist. 
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Zusammenf as sung 

Verfahren zum Ubermitteln von geschtitzten Inf ormationen an 
mehrere Empfanger 

5 

Erste Informationen, die far einen ersten Empfanger bestimmt 
sind, werden zusammen mit zweiten Informationen, welche fur 
einen zweiten Empfanger bestimmt sind, in einer gemeinsamen 
Informationseinheit an den ersten Empfanger versendet. Die 

10 ersten Informationen konnen dabei gemafl den Vorgaben des ers- 
ten Empf angers verschlusselt sein. Die zweiten Informationen, 
welche aus mehreren Bestandteilen bestehen konnen, werden ge- 
ma£ den Vorgaben des zweiten Empfangers verschlusselt, bei- 
spielsweise mit einem offentlichen Schlussel, einem sogenann- 

15 ten ^public key 7 ' . Diese ^public key 77 Verschlusselungsverf ah- 
ren sind bereits in verschiedenen Ausf uhrungen. und Sicher- 
heitsstufen bekannt. Durch dieses Vorgehen wird gewahrleis- 
tet, dass der erste Empfanger bei Erhalt der kompletten In- 
formation die fur ihn nicht bestimmten Inf ormationsanteile 

20 nicht entschlusseln kann. 
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BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

a 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



